ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group98a.txt/000054_icon-group-sender _Tue Feb 24 16:49:24 1998.msg

Internet Message Format | 2000-09-20 | 6KB

Return-Path: <icon-group-sender>
Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
    by baskerville.CS.Arizona.EDU (8.8.7/8.8.7) with SMTP id QAA00972
    for <[e-mail]>; Tue, 24 Feb 1998 16:49:15 -0700 (MST)
Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
    id AA24084; Tue, 24 Feb 1998 16:49:14 -0700
Message-Id: <[e-mail]>
Date: Tue, 24 Feb 1998 15:52:49 -0600
From: Mark Evans <[e-mail]>
Reply-To: [e-mail]
Organization: None
X-Mailer: Mozilla 3.01 (Win95; I)
Mime-Version: 1.0
To: Ken Walker <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: icon questions
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Errors-To: [e-mail]
Status: RO
Content-Length: 4585

Ken Walker wrote:

> The -c option of iconc will produce C source code. However, the source
> code is only suitable for compiling and linked to a run-time system. It
> is not meant for human consumption. As an example, I translated
> a simple "hello, world" program. It produced two files. The .h file
> is



All of the major problems relate to the run-time support system.  I
presume that this is described in "rt.h"?  I am speaking ad lib as I
have not used the Icon --> C converter.



> More complex programs only get worse...



That is true in the general case regardless of language.  In the
specific case of going from Icon --> C, the complexity makes sense
because the port is from a high-level, compact language to a low-level
system language.  I have no problems with that.  It seems natural to
me.  That is the whole point of the endeavor:  to have the computer work
out the details so that you can focus on higher level abstractions.  If
the C output were *not* complicated-looking, I would have to ask whether
I had gained anything over writing the C myself in the first place.

When I read on the dust jacket of the Icon book that it takes ten times
less code to do an algorithm in Icon, I would fully expect the C code to
be ten times as large as the Icon source.  If we could find a way to
build a front-end language and C-generator with an even better ratio,
like 100 times, I would be all for it.

Modern C++ compilers are very complicated affairs but the world couldn't
get along without them, not easily.  They take care of inheritance and
run-time dispatch issues so you don't have to.  Have you ever looked at
the output of CFront?

I would like an Icon-->C generator of similar capability.  Just as
CFront knows about classes and their details, I want the Icon-->C
converter to know about generators and goal-directed evaluation and
their details.

We are basically talking about improving our tools, just like the
progression from stone to axe to plane to mill to laser.



> There are several problems with translating Icon into C. Some of
> the major problems are:
>
>    - you must implement goal-directed evaluation in a laguage
>      that has none. In some cases, with enough optimization, it
>      can be converted into loops. But in other cases the best
>      technique we have come up with involves breaking the program
>      into lots of little functions and passing function pointers
>      around everywhere. This is not your typical C code.



Perhaps this characteristic just reveals that traditional C is not
efficient of expression.  Efficiency or compactness of expression may
require function pointers.  Since Icon by nature is meant to break new
ground, I would not be surprised to find that it translates into unusual
C code.

I have used function pointers a few times in my C work.  I was always
quite pleased whenever I found a use for them.  The result always struck
me as being elegant.  Function pointers are one of the neat things about
C.  Don't forget that they are used all over the place in the run-time
systems of C++ compilers (dispatch tables to member functions).  That
should be a clue that function pointers can really get you places.



>    - variables must be able to hold any value, and values must include
>      type information. In some cases, if you do enough analysis, you
>      can remove these requirements, but in general you cannot.

It seems to me that this requirement is not a hard one to handle.  Why
bother eliminating it?


>    - variables have to be implemented in such as way that the garbage
>      collector can find them.

Dangling pointers are the #1 bug in C code.  When you implement an
automatic garbage collector that does this job for the programmer, you
have eliminated most of his bugs.  You have created a better tool.


> Converting Icon programs into C is much more interesting than it
> appears on the surface :-)
>
> Ken Walker, [e-mail]
> Harbinger Coporation, Concord, Ca. 94520


You can look at these "problems" in a more optimistic light.  Turn the
thing around; all the major problems are confined to the run-time
support system.  Therefore, if the run-time support system is properly
written, then it should be easy to convert Icon source to C.

The interpreter is implemented in C, so there should be a reasonable
means of implementing its run-time support system as a C-callable
library.  Then this library source code would be part of the generated C
code from iconc.

The obstacles may be hard, but they are surmountable.

Mark Evans
[e-mail]